1. Field of the Invention
The invention relates to a networked workstation system for software development. More particularly, the invention relates to coordinating the work of multiple users of the networked workstation system during creation of a software product. Still more particularly, the invention relates to a networked workstation system providing automated management of the design through the implementation of the software application.
2. Description of the Prior Art
Software includes computer programs, routines, programming languages and systems, and supporting documentation for any of the above. It extends to detailed procedures to be followed by a computer or its operator and thus includes documents such as handbooks, drawings, program listings and diagrams supporting use of an application on a computer. In its broadest sense, software will comprise all materials and procedures other than hardware relating to execution of a function or family of functions on a computer system. During the lifetime of a software product, additional documents or records that would be of interest to the product may be created. For example, for diagnostic purposes a complete record of all revisions may be valuable. Customer comments and requests regarding a document may also be logged.
In a formal development setting, the seed of a programming application is the request document. The request document describes, typically in general terms, the desired ends of the program application. From the request document, an objective document is prepared specifying attributes of the programming application including: (1) functional features; and (2) the user interface. Upon completion of an initial objective document, generation of specific design documents begins. The documents include functional specifications characterized by performance results required for operation on specified bodies of data. Another design document is the programming specifications which outline how the functional specifications are to be met. The request document, the objectives document, the functional specification and the programming specification together constitute a textual record of the development of a system. Completed design documents support programmer generation of source code for the application. Blocks of source code are an explicit ordering of the instructions to be carried out on a computer system.
Any major programming application development project involves dozens to hundreds of designers and programmers, frequently scattered among several locations. Management of such a project, particularly management aimed at generating and preserving a coherent body of supporting documentation relating to the project, has become a cumbersome undertaking. The management task of assuring that appropriate and timely supporting materials reach the designated people at the correct moment has been difficult. Also difficult has been the sufficient appraisal of designers, developers, programmers and testers of the tasks facing nonmembers of their respective groups.
The term programming environment has been used to refer to the operating system environment and the collection of tools and subroutines with which software is developed. See for example, Leblang et al. "Computer-Aided Software Engineering in a Distributed Workstation Environment", reprinting in proceedings of the ACM Sigsoft/Sigplan Software Engineering Symposium on Practical Software Developments Environments, Pittsburgh, Penna., 23-25 Apr. 1984. Leblang et al. describe an environment based on several managers, including a history manager which controls source code and provides complete version histories, a configuration manager which builds systems from their components and detects the need to rebuild, a task manager which relates source code changes made to nodes throughout a network to a particular higher level activities, a monitor manager which watches user-defined dependencies and alerts users upon triggering of certain dependencies, and an advice manager which holds general project related information and provides templates for redoing common tasks.
Concepts relating to control of relationships between individuals in a networked workstation system are also of relevance to the present invention. Bly et al., U.S. Pat. No. 5,008,853, discloses a multiuser collaborative system operating on a real-time basis. The particular focus of Bly et al. is the multiuser interface. Another aspect of Bly et al. are methods relating to access of "structured data objects". The term structured data object is used generically to denote a data object that contains a series of other data objects linked together in a predetermined manner and which may include a visual representation or a functional abstraction for a display screen. Member data objects of the structured data object may have associated sets of operations brought together for one or more functional purposes. An example of a structured data object is a word processing document with several pages, where each page is a data object and pages are preceding and subsequent pages in a predetermined order. A structured data object that is capable of holding other structured data objects is referred to as a container. Bly discloses employment of containers in a shared multiuser environment, where it is accessible to more than one user through a plurality of network coupled personal workstations.
Representation of a structured data object in iconic form is discussed at column 2, lines 50-55 of Bly et al. Among the iconic representations are a container type known as a book, which is a special directory that creates a relationship among document portions within the book. Consecutive documents in a book can share a single page number series and there is a facility to automatically create a table of contents and index.
Structured data objects, such as file folders and documents digitally stored in a file drawer, can be shared by many users in accordance with individually assigned access rights. This is accomplished by placing a digital copy of a structured data object on the user's desktop metaphor for the user's subsequent manipulation. Communications of revisions among users, if desired, must be specifically provided for.
Bly et al. specifically relates to construction of a publication management system. (See column 11, lines 32-61). The system is implemented through the abstraction of a shared book metaphor. The desktop metaphor of each workstation includes an abstraction representing the shared data structure, which abstraction is referred to as the shared book. A new book is begun by replication of a blank shared book and naming the replicated structure. Upon opening of a shared book by a user, a listing of entries, analogous to a table of contents, is displayed. However, a shared book does not admit other container type files (see column 18, lines 50-60). Beyond the pages of text for the shared book, the shared book also includes a property sheet providing fields for items that concern the shared book as a whole. These include the shared book's name, its file service, its database, its access list, the number of remote consecutive versions among other operational details.